When BibDB does not work as expected, it can be for one of four reasons:
In developing BibDB, I tried to make the use as easy and automated as possible, especially when dealing with files — bibliography, dump, configuration and auxiliary files. Unfortunately, this has had the effect of introducing new opportunities for incompatibilities and other problems. Most of the problems you might encounter will have to do with the way BibDB searches for and treats files, and the most vulnerable place is the treatment of auxiliary files. I will therefore elaborate on the way BibDB treats them.
Auxiliary files are used by BibDB whenever a change is to be made to the bibliography file. BibDB uses up to four auxiliary files at the same time. During normal operation of BibDB, these files are placed in a directory which is specified by the `auxdir' configuration file parameter, or the `/a' command line parameter, if specified. Their names are generated by the DOS ``$5A'' function, which ensures that they are unique — the auxiliary files can't overwrite existing files, including auxiliary files of BibDB running on a different task. The auxiliary directory is chosen from the list provided by `auxdir' using the following criteria: the directory (this includes a memory type specification) must exist, must be writable, and must have at least the maximum of the first `FreeDiskRequired' number, and the size of the current bibliography file + the second `FreeDiskRequired' number free bytes of disk space (the size requirements for the second file are slightly different — the minimum free space is the value of the third `FreeDiskRequired' parameter). The first directory from the directory list that meets these criteria is chosen as the auxiliary file location. If no directory meets these criteria for the main auxiliary file, file editing is switched off, while if no directory meets them for the second auxiliary file, checking for duplicate names is switched off. The `auxdir' parameter is scanned at startup, whenever the bibliography file is changed (if `auxdir' includes the `[bibdir]' string), whenever the `auxdir' parameter is changed, and whenever there is not enough disk space in the selected auxiliary directory. All auxiliary files are deleted upon normal termination of BibDB. All but one of the auxilliary ``files" may in fact reside in XMS or EMS memory, rather than on a disk.
On some systems which are not perfectly IBM PC compatible, it may happen that some of the procedures outlined above may fail. It is possible to ask BibDB to display the names of the auxiliary files it generates, by specifying `/debug' on the command line. If the resulting directory is not to your liking, changing the `auxdir' parameter might solve your problem. You might try to leave out the `[bibdir]' option, and specify just a single directory, which you know to exist.
BibDB has been reported to be incompatible with the DOS JOIN command, whenever the bibliography file is situated on a JOINed disk. In this respect, I would just note that BibDB is far from being the only program to suffer under JOIN (the full list includes, among others, the DOS commands BACKUP, RESTORE, DISKCOPY and DISKCOMP, amd Microsoft have in fact left out JOIN from MSDOS 6.2). In general, it is bad PC practice to use JOIN — it is better to format your disk to have large partitions. Some reports have also indicated some compatibility problems with DrDOS 6.0 (although it worked fine for me), which are however solvable by playing around with the `auxdir' parameter.
The EMS usage of BibDB for the auxiliary files has been reported to be incompatible with several memory managers, including QEMM and OS/2 2.0 . For this reason, I have omitted it from the default configuration file. If you wish, you may turn it on carefully, and see what happens. XMS usage is fine, though, and should be enough for most people.
You may come across the error message that BibDB can't find a command line interpreter, and that consequently shelling to DOS is disabled. BibDB looks for the command line interpreter by reading the value of the COMSPEC environment variable. If COMSPEC is not set, BibDB looks for the files `4DOS.COM' and `COMMAND.COM' in the directories `C: \4DOS', `C: \DRDOS', `C: \DOS' and `C: \', in that order. Make sure that your command line interpreter is present in one of these locations, or point to it using `COMSPEC'.
It may happen that the EXE file you are running is corrupted. You can easily check this by switching on the selftest in the configuration file (this is in general a good thing to do the first time you run BibDB). If the file is indeed corrupted, the only thing to do is to get a new copy.
If the above procedures do not help, you may have come across a bug in BibDB (this is not unheard of). If you conclude that your problems stem from a bug in BibDB, please let me know. Let me know also if you come across an incompatibility. Try to specify in your message all relevant information, including your `autoexec.bat' and `config.sys' files, configuration file, DOS version, CPU, which disks you are working on, a sample of your bibliography file, special modes and TSRs, the result of the DOS ``mem" command, and whatever else you think is relevant. I must be able to reconstruct the problem here, or I will not be able to correct it. Be prepared for the possibility that I will use you as a beta tester for that problem. Also note that if your problem is hardware related (e.g. special cards or adapters), I may be unable to deal with it. The same may also be true for the more unusual PC configurations. Please remember that I am a single individual working on my own time, and not a commercial company — I will do my best (time permitting), but I promise nothing.